1. Technical Field
The present invention relates in general to error isolation in data processing systems and in particular to debugging the dump file of an operating system within a data processing system. Still more particularly, the present invention relates to reducing the size and complexity of an operating system dump file to be debugged.
2. Description of the Related Art
"Lean client" devices, also referred to as network computers, are finding widespread acceptance for corporate computing needs, which typically may be satisfied largely through use of a limited set of applications, The increasing popularity of such devices and the advent of new programming languages such as Java has led to the development of new operating systems. For example, JavaOs provides a standalone application platform designed specifically for network computers. JavaOS utilizes a layered architecture, where each layer can be independently updated, and includes a microkernel and memory manager, device drivers, the Java Virtual Machine (JVM), graphics and windowing systems, networking classes, and support for the full Java API.
JavaOS employs and conforms to the Java programming language specification which, like several other programming languages such an LISP and SNOBOL, utilizes a memory management model a including "garbage collection" scheme. Various garbage collection schemes are known in the art, many of which are described in Garbage Collection: Algorithms for Automatic Dynamic Memory Management (ISBN 0471941484). Mark-sweep garbage collection, for example, involves recursively following pointers from a set of base pointers and setting a mark bit for each storage area identified by a pointer within an actively used storage area, then sweeping the storage structure looking for unmarked allocations and deallocating disconnected storage. As another example, garbage collection may be based upon a reference-counting mechanism which increments the reference count of an object contained within allocated storage when a live reference to that object enters the Java virtual machine.
With all garbage collection schemes, system memory allocation is periodically examined by surveying pointers or memory references. As long as at least one live reference exists for an object, the object cannot be garbage-collected and the storage containing the object cannot be deallocated. When no live references or pointers are found referencing an object or a specific, allocated portion of system memory, that memory is deallocated. This memory region is called "disconnected storage." System memory is then purged of inaccessible or "disconnected" storage objects--previously allocated storage which is no longer accessible because no remaining pointers from actively utilized storage areas to the subject storage area exist--while remaining objects are consolidated or moved to eliminate fragmentation between active, allocated storage areas. As objects are moved, all pointers referencing the object are updated with the object's new location.
Garbage collection eliminates the need for programmers to explicitly deallocate memory and automatically reduces fragmentation. In the Java VM, since garbage collection automatically reduces fragmentation of system memory, the garbage collection memory management scheme is well-suited for compact data processing systems having limited memory resources. The use of ouch a scheme in an operating system tailored for lean client or network computers is thus a logical choice.
During debug, a system dump of the entire memory is typically taken at the time of failure. Afterward, programmers must go through this dump looking for the problem which caused the failure. In a Java environment for example, due to the garbage collection scheme of memory deallocation, extra data not yet deallocated by garbage collection is generally present within the system dump. This increases the size of the data dump, slows down searches through the dump, and in some cases may lead to false search results since possibly pertinent data may appear to be located within disconnected storage. This may result in the debugging process taking longer, and may even hinder successful debugging of the system failure.
Garbage collection, while known in the art, is essentially a mechanism for keeping a data processing system running smoothly and efficiently by automatically deallocating disconnected storage. System dumps, on the other hand, are taken after a data processing system has crashed and is no longer running. Therefore, the need for automatically deallocating disconnected storage no longer exists at the time the system dump is taken or debugged. Accordingly, post dump garbage collection has not previously been considered in the art.
It would be desirable, therefore, to reduce the occurrences of disconnected storage within a system memory dump after system failure.